遥控体验好不好跟网络有很大关系。为了达到遥控体验的上限，我们需要非常先进的遥控算法技术，也需要网络状态足够稳定；但在现实中，很多需要远程控制的场景并没有特别稳定的网络，甚至可以称为“弱网络环境”，保证远程控制体验的“下限”也很重要这样的场景。

针对弱网环境下的诸多问题，《全民遥控向日葵》引入了BBR拥塞控制算法，使服务器之间的连接更快，端与服务器的连接更稳定，从而提高向日葵在弱网络环境。连接稳定性和带宽利用率。

这里先介绍一下BBR拥塞控制算法是什么，这个算法是怎么开发出来的，向日葵引入这个算法的效果是什么。

什么是拥塞控制算法

要理解拥塞控制算法，我们首先要简单解释一下网络为什么会丢包。

在互联网上进行两点通信时，每经过一个路由设备就称为一跳（hop）。每一跳都有不同的带宽，两点之间的可用带宽是每一跳中的最小值，称为BW。因为是公用链路，所以拥塞、丢包、排队等问题在所难免，可用带宽也时不时变化。这是网络冻结的根本原因之一。

但是网络通信有补救机制。即使排队和路由抖动导致丢包或数据错误，4层TCP协议也会处理。它将重新传输并执行带宽控制以确保数据完整性。它是拥塞控制算法的核心。

早期三次拥塞控制算法

1980 年代互联网的崩溃导致引入了 TCP 拥塞控制。经过十多年的发展，Cubic出现并延续到Ling，至今仍是互联网主流的拥塞控制算法。表示道路拥堵。通过检测丢包，可以发现并主动降低发送频率以减少拥塞。这被称为“基于损失的”拥塞控制算法。类似的算法还有好几种，比如早期的Reno、BIC等。

由于丢包只发生在路由器的队列满时，这种算法往往会迅速填满瓶颈路由器的缓存谷歌优化，然后急剧减少数据包数量（减少50%），然后慢慢减少。队列空闲。一遍又一遍地填满它。

Cubic算法的正常运行对链路的丢包率有一定的要求。在丢包率高的长胖管道环境下，它的发送窗口会很快收敛到较小的尺寸。另一方面，当实际可用带宽增加时，总是需要一个固定的时间来检测，然后逐渐增加，效率相对较低。

同时，Cubic会在拥塞避免阶段逐渐增加发送窗口，直到填满瓶颈队列。这种机制加速了拥塞的形成，并导致网络延迟的波动。因此，在链路瓶颈处保持最大带宽和最小延迟的状态是拥塞控制的目标谷歌优化，但显然Cubic在目前的互联网环境下不是很胜任。

谷歌提出BBR拥塞控制算法

基于上述Cubic算法的不足，谷歌提出了一种基于延迟-带宽积BBR（和RTT）的算法，采用交替测试链路的最大带宽和最小RTT的方法来找到最优化的工作点，这个点，核心特征是数据包开始排队。如下图，Cubic的拥塞控制点排队，缓存已满。

将最近 10 次往返测得的最大带宽设为 Bmax，将过去 10 秒内测得的最小 RTT 设为 Tprop，然后根据这两个值估算 BDP。

BBDP = Bmax × Tprop

BBR分别通过窗口增益和起搏增益调整CWND和传输速率，进而控制其传输行为，将拥塞快速收敛到最优控制点。

向日葵使用BBR算法将连接带宽提升3倍以上

向日葵基于BBR算法的优势，将其引入并应用在远程控制技术中。根据向日葵的实验室数据，在跨国弱网络环境下，单连接应用无需复用，BBR 可以将终端与服务器之间的可用带宽提高 10 倍左右（例如，从 >1Mbps 起）。同时，在国内服务器互联时，BBR可以将服务器之间的带宽利用率提高1倍以上（从40%提高到85%）。

实际使用中，通过支持BBR的服务器后，向日葵的连接带宽提升3倍以上，帧率提升5倍以上，显着提升了用户体验。

在BBR算法的加持下，我们可以明显感受到向日葵遥控器的“下限”有非常充足的保障。当遥控器应用在很多弱网络环境中，比如工业、户外等场景，相信向日葵可以充分发挥技术优势。